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(54) DATA TRANSFER METHOD 

(57) A data transfer method which eliminates erro- 
neous operation of conventional devices not supporting 
encryption when copy-protected AV information is 
encrypted and sent on the IEEE 1394 bus. Synchro- 
nous data transferred through isochronous communica- 
tion contains i) encryption identification information for 
indicating encryption of actual data and ii) actual data. 
Only the actual data is encrypted. Encryption identifica- 
tion information indicating encryption status of actual 

906 



data in synchronous data is sent together with actual 
data from the sending device. A receiving device detect- 
ing encryption of actual data from this encryption identi- 
fication information requests for decrypting information 
to the sending device. The receiving device decrypts 
the actual data using decrypting information received 
from the sending device according to this request. 
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Description 

FIELD OF THE INVENTION 

[0001] The present invention relates to the field of dig- 
ital data transfer methods, more particularly to the trans- 
fer of data in which normal digital data and encrypted 
digital data co-exist in the same data. 

BACKGROUND OF THE INVENTION 

[0002] One conventional data transfer method adopts 
the IEEE1394 standard (IEEE: The Institute of Electrical 
and Electronics Engineers, Inc.). (Reference: IEEE Std 
1394: 1995, High Performance Serial Bus.) In data 
transfer specified by the IEEE 1394 standard, there are 
two methods of communication. One is isochronous 
communication, which is suitable for transferring syn- 
chronous data such as digital video signals and digital 
audio signals. The other is asynchronous communica- 
tion, which is suitable for transferring asynchronous 
data such as control signals. Both methods of commu- 
nication are applicable on the IEEE 1394 bus network. 
Isochronous communication is what is called "Broad- 
cast communication, and an isochronous packet output 
from one device coupled to the IEEE 1394 bus is receiv- 
able by all the other devices coupled to the same bus. 
On the other hand, asynchronous communication is 
applicable to both one-to-one communication and one- 
to-N broadcast communication. Each asynchronous 
packet output from one device coupled to the bus con- 
tains an identifier specifying the device(s) to which that 
packet is addressed. If this identifier specifies a particu- 
lar device, only the device specified by the identifier 
receives the asynchronous packet. If the identifier spec- 
ifies broadcast, all the devices coupled to the same bus 
receive the asynchronous packet. 
[0003] At present, the IEC (International Electrotech- 
nical Commission) is preparing to stipulate the IEC1 883 
standard (hereafter referred to as AV protocol) for trans- 
ferring digital audio signals and digital video signals or 
transmitting data between devices coupled to an IEEE 
1394 bus. employing the data transfer method conform- 
ing to the IEEE 1394 standard. In the AV protocol, video 
and audio data is located in the isochronous packet as 
shown in Fig. 5 and transferred. The isochronous 
packet includes a CIP (Common Isochronous Packet) 
header. The CIP header carries information that 
includes the type of AV data, the identification number 
of the device which is sending the isochronous packet, 
and the like. 

[0004] Fig. 5 shows the format of the isochronous 
packet used in the AV protocol. The isochronous packet 
comprises an isochronous packet header 900, header 
CRC 901. isochronous payload 902. and data CRC 
903. "Tlie isochronous packet header 900 contains a tag 
907. The tag 907 shows that the isochronous packet 
conforms to the AV protocol when its value is 1. When 



the value of the tag 907 is 1 , which means that the iso- 
chronous packet conforms to the AV protocol, the iso- 
chronous payload 902 has a CIP header 904 at its 
beginning. The CIP header 904 comprises a source ID 

5 906 which identifies the device transmitting the iso- 
chronous packet. The CIP header 904 also comprises 
FMT 908 and FDF 909 which specify the type of actual 
data 905 in the isochronous payload 902. Digital AV 
data is contained in the actual data 905. but the actual 

10 data 905 is not always contained in the isochronous 
payload 902. Some packets may have an isochronous 
payload 902 which contains only the CIP header 904 
without the actual data 905. 

[0005] There is a group of commands called the AV/C 
15 Command Set for controlling devices in accordance 
with the AV protocol (Reference: 1394 TRADE ASSO- 
CIATION Specification for AV/C Digital Interface Com- 
mand Set Version 1.0, September 13, 1996). These 
commands and their responses are transferred by 
20 means of asynchronous communication. 

[0006] In the conventional data transfer method as 
described above, compatibility with conventional 
devices which are not designed for transferring an 
encrypted isochronous payload 902 cannot be secured 
25 when an encrypted isochronous packet, which contains 
the isochronous payload 902 which has been encrypted 
for copy protection, is sent. More specifically, conven- 
tional devices are designed with the precondition that 
the CIP header 904 is normally positioned at the begin- 
so ning of the isochronous payload 902. Accordingly, if the 
isochronous payload 902 is encrypted, conventional 
devices cannot correctly read out the encrypted CIP 
header 904, and decide that the isochronous packet 
does not conform to the AV protocol. A device receiving 
35 encrypted isochronous packets thus may not operate 
properly. In other words, such receiving devices cannot 
determine the type of data contained in the actual data 
905, resulting in an inability to identify the device trans- 
mitting the isochronous packet. In addition, asynchro- 
40 nous communication such as queries to the sending 
device are disabled. Accordingly, normal receiving oper- 
ations cannot be carried out 

[0007] Furthermore, if the isochronous packet output 
from the sending device is encrypted while the receiving 
45 device is receiving the data, some conventional devices 
may not be able to correctly read out the CIP header 
904 as soon as encryption starts, resulting in inability to 
receive data properly. 

[0008] In order to send AV information encrypted for 
so copy protection from the sending device and decrypt the 
encrypted AV data by the authorized receiving device, 
the sending device needs to give decrypting information 
to the authorized receiving device. In the conventional 
data transfer method, however, the sending device may 
55 be required to execute extremely complicated proce- 
dures in order to specify the receiving device. More spe- 
cifically, each isochronous packet contains the source 
ID 906 which is the identifier of the sending device, but 
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these packets do not contain information that identifies 
which device is authorized to receive these packets. 
The sending device thus cannot check which device is 
receiving the isochronous packets during transmission 
of the isochronous packets. In order to find which of the 
devices coupled to the IEEE 1394 bus is receiving the 
data, the sending device may require to query the data 
receiving status of every device coupled to the same 
bus. This makes the procedures for giving key informa- 
tion for decryption extremely complicated. 

SUMMARY OF THE INVENTION 

[0009] A data transfer method of the present invention 
satisfies the conventional communication standard even 
in the case of sending encrypted video and audio infor- 
mation via isochronous communication. In addition, the 
present invention offers a data transfer method which 
prevents erroneous operation even if conventional 
receiving devices receive isochronous packets contain- 
ing encrypted video and audio data. 
[001 0] The present invention still further offers a data 
transfer method which significantly simplifies proce- 
dures for giving key information for decryption from a 
sending device to an authorized receiving device. 
[001 1 ] In a data transfer method of the present inven- 
tion, synchronous data transferred via isochronous 
communication contains i) encryption identification 
information which indicates encryption status of actual 
data and ii) actual data, and only the actual data is 
encrypted. 

[0012] To solve another problem in the conventional 
data transfer method, the encryption identification infor- 
mation which indicates encryption status of the actual 
data in the synchronous data is sent together with the 
actual data from the sending device so that receiving 
device can detect that the actual data is encrypted 
based on this encryption identification information and 
request decrypting information to the sending device in 
the data transfer method of the present invention. Then, 
the receiving device receiving the decrypting informa- 
tion sent from the sending device upon request decrypts 
the actual data using this decrypting information to com- 
plete data transfer. 

[001 3] Also in the data transfer method of the present 
invention, the receiving device receiving synchronous 
data checks for the encryption identification information 
contained in the synchronous data. If the receiving 
device detects that the actual data is encrypted, the 
receiving device requests for decrypting information for 
decrypting the actual data to the sending device. This 
request is made using a command in the AV/C set via 
asynchronous communication. At receiving this 
request, the sending device checks the packet header 
of received command to identify the device making the 
request, i.e., the receiving device. The sending device 
then gives decrypting information to the identified 
receiving device using a command via asynchronous 



communication, enabling to realize the data transfer 
method with extremely simple procedures for giving 
decrypting information from the sending device to 
receiving device. 
5 [0014] Moreover, in the data transfer method of the 
present invention, only the actual data in the synchro- 
nous data is encrypted, and the encryption identification 
information indicating the encryption status of the actual 
data is included in the synchronous data. This enables 
10 to transfer the CIP header without being encrypted, pre- 
venting erroneous operation when the conventional 
device receives such encrypted synchronous data. In 
other words, the present invention realizes a data trans- 
fer method which assures compatibility with the conven- 
ts tional data transfer method and eliminates the 
possibility of erroneous operation when the conven- 
tional receiving device receives encrypted synchronous 
data. 

[0015] Furthermore, the data transfer method of the 
20 present invention eliminates the possibility of erroneous 
operation of the receiving device receiving data when 
encryption of synchronous data starts while continu- 
ously receiving synchronous data from the sending 
device because the CIP header is not encrypted and 
25 transferred as it is. 

BRIEF DESCRIPTION OF THE DRAWING 
[0016] 

30 

Fig. 1 is a schematic view of a format of a CIP 
header in accordance with a preferred embodiment 
of the present invention. 

Fig. 2 is a block diagram illustrating functions of 

35 sending and receiving devices in accordance with 
the preferred embodiment of the present invention. 
Fig. 3A is a format of AKE status command in 
accordance with the preferred embodiment of the 
present invention. 

40 Fig. 3B is a format of AKE response to the AKE sta- 
tus command in accordance with the preferred 
embodiment of the present invention. 
Fig. 3C is a format of AKE control command in 
accordance with the preferred embodiment of the 

45 present invention. 

Fig. 4 is a schematic view illustrating procedures for 
transmitting an asynchronous packet between 
sending and receiving devices in accordance with 
the preferred embodiment of the present invention. 

so Fig. 5 is a format of isochronous packet in a data 
transfer method of the prior art. 

DESCRIPTION OF THE PREFERRED EMBODIMENT 

55 [001 7] A preferred embodiment of the present inven- 
tion is described next with reference to drawings. 
[001 8] Fig. 1 shows a format of the payload of an iso- 
chronous packet to be transferred in the preferred 



5 



EP 0 978 965 A1 



6 



embodiment of the present invention. The preferred 
embodiment is one example of the transfer of a TSP 
(Transport Packet) in accordance with MPEG (the Mov- 
ing Picture Expert Group) specifications. The ENC 
(hereafter referred to as encryption status) 910 indi- 
cates whether the actual data 905 is encrypted or not. 
[001 9] Fig. 2 shows the relation between sending and 
receiving devices in the preferred embodiment of the 
present invention. A sending device 110 and receiving 
device 128 are coupled via an IEEE 1394 bus (hereafter 
referred to as a 11394 bus) 111. 

[0020] First, the functions of each block in the sending 
device 1 10 are described. 

[0021] A signal source 100 outputs an MPEG trans- 
port packet TSP (not illustrated) in an 188 byte unit, 
which will be sent via the 1 394 bus 1 1 1 , to an encrypter 
101. In other words, in the preferred embodiment, the 
signal source 100 outputs data with a fixed length of 1 88 
bytes. The encrypter 101 encrypts and outputs the TSP 
received from the signal source 100 using an encryption 
key 109 provided by a key generator 106. In the pre- 
ferred embodiment, the encryption key is equivalent to 
the decrypting information. An output command 105 is a 
command from the key generator 106 to the encrypter 
101. There are three types of commands: normal out- 
put, encrypted output, and empty output. If the 
encrypter 101 receives the output command 105 for 
normal output, the TSP received from the signal source 

100 is output without modification, and registers the 
value 0 as the encrypting information 910. If the output 
command 105 is for encrypted output, the encrypter 

101 encrypts the TSP with the encryption key 109 
received from the key generator 106, and registers the 
value 1 as the encrypting information 910. If the output 
command 105 is for empty output, the encrypter 101 
outputs an empty signal (not illustrated) every time it 
receives a TSP from the signal source 100, and regis- 
ters the value 1 as the encrypting information 910. A 
source packet generator 102 adds a 4-byte source 
packet header to the 188-byte TSP received from the 
encrypter 101, and outputs a 192-byte source packet 
(actual data 905). A CIP block generator 1 03 adds a CIP 
header 954 to the source packet received from the 
source packet generator 102, and outputs an iso- 
chronous payload 952. Here, the CIP block generator 
103 places the encrypting information 910 received 
from the encrypter 101 in the CIP header 954. An iso- 
chronous packet generator 107 adds an isochronous 
packet header 900, header CRC 901, and data CRC 
903 to the isochronous payload 952 received from the 
CIP block generator 103, and outputs an isochronous 
packet. Since the content of the isochronous payload 
952 is data that conforms to the AV protocol, the value 
of the tag 907 is set to 1. The key generator 106 sends 
the encryption key 109 to the receiving device 128 by 
communicating the asynchronous packet with the 
receiving device 128, as shown in Fig. 3, which is 
described later. The key generator 1 06 also outputs the 



encryption key 109 to the encrypter 101 as described 
above. 

[0022] A 1394 packet I/O means 108 inputs and out- 
puts isochronous and asynchronous packets between 

5 the 1394 bus 1 1 1 and sending device 1 10. More specif- 
ically, the 1394 packet I/O means 108 outputs the iso- 
chronous packet received from the isochronous packet 
generator 107 and asynchronous packet received from 
the key generator 106 to the 1394 bus 111. and also 

w outputs asynchronous packet received from the 1394 
bus 1 1 1 to the key generator 106. 
[0023] Next, functions of each block of the receiving 
device 128 are described. 

[0024] A 1394 packet I/O means 127 inputs and out- 
15 puts isochronous and asynchronous packets between 
the 1394 bus 111 and receiving device 128. More spe- 
cifically, the 1394 packet I/O means 127 outputs the iso- 
chronous packet received from the 1394 bus 111 to a 
payload extractor 123, and outputs asynchronous 
20 packet received from the 1394 bus 1 1 1 to a key genera- 
tor 125. The 1394 packet I/O means 127 also outputs 
asynchronous packet received from the key generator 
125 to the 1394 bus 111. 

[0025] The payload extractor 123 receives the iso- 
25 chronous packet transmitted from the 1394 bus 111, 
from the 1394 packet I/O means 127. When the value of 
the isochronous packet tag 907 is 1 , the payload extrac- 
tor 123 determines that an isochronous payload 952 
contains data conforming to the AV protocol, and out- 
30 puts the isochronous payload 952 to an actual data 
extractor 122. When received isochronous payload 952 
contains the actual data 905, the actual data extractor 
122 outputs the actual data 905 to a decrypter 121 , after 
removing the CIP header 954 placed at the beginning of 
35 the isochronous payload 952. The actual data extractor 
122 also outputs the source ID 906 and encrypting infor- 
mation 910 extracted from the CIP header 954 to the 
key generator 125. The encrypting information 910 is 
also output to the decrypter 1 21 . The key generator 1 25 
40 receives an encryption key 126 as a result of exchang- 
ing asynchronous packet with the sending device 110 
via asynchronous communication, which is described 
later, and outputs the encryption key 126 to the 
decrypter 121. When the value of the encrypting infor- 
ms mation 910 received from the actual data extractor 1 22 
is 0, the decrypter 121 outputs the actual data 905 
received from the actual data extractor 122 to an AV 
generator 120 as it is. When the value of the encrypting 
information 910 is 1, the decrypter 121 decrypts the 
so actual data 905 using the encryption key 126 received 
from the key generator 125, and outputs decrypted 
actual data 905 to the AV generator 120. 
[0026] Next, the transmission of an asynchronous 
packet via the aforementioned asynchronous communi- 
55 cation setup is described. 

[0027] Figs. 3A to 3C illustrate how the format of the 
asynchronous packet is transmitted by asynchronous 
communication. More specifically. Figs. 3A and 3C 
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shew the command formats of the AKE commands 
(AKE: Authentication and Key Exchange) communi- 
cated between the key generators 106 and 125. Fig. 3B 
shows the response format. These commands and 
responses belong to the AV/C Command Set and are 
communicated between the sending device 110 and 
receiving device 1 28 using the asynchronous communi- 
cation. By communicating these commands and 
responses, the sending device 110 and receiving device 
128 exchange information required for the authentica- 
tion of each other and encryption keys 109 and 126. 
The AKE commands comprise AKE control commands 
for requesting a target device to carry out a specific 
operation, and an AKE status commands for querying 
the status and capabilities of the target device. 
[0028] Fig. 3A shows the format of the AKE status 
command. In the AKE status command, an operation 
code 208 indicates that this command is an AKE com- 
mand. The value of the algorithm ID 200 is set at 0, with 
other values reserved for future extension. 
[0029] Fig. 3B shows the format of responses to the 
AKE status commands. This is a response sent back 
from the device receiving the AKE status command to 
the device issuing the AKE status command. There are 
multiple procedures for exchanging information for 
mutual authentication and transmission of encryption 
keys 109 and 126 between the sending device 110 and 
receiving device 128. In an algorithm field 201 , the iden- 
tifier for an information exchange procedure which the 
device returning an applicable response can execute is 
assigned in bits. In other words, the receiving device 
1 28 exchanges several commands and responses with 
the sending device 110 after an encrypted TSP is 
detected in line with the aforementioned procedures 
and before receiving the encryption keys 109 and 126. 
There is more than one procedure for communicating 
these commands and responses. The device sending 
back the response designates the executable informa- 
tion exchange procedure by setting 1 to an applicable 
bit in the algorithm field 201. Since the size of the algo- 
rithm field 201 is 16 bits, a maximum of 16types of infor- 
mation exchange procedures can be indicated. The 
maximum data length 212 indicates the longest receiv- 
able data length in the form of bytes for exchanging AKE 
commands and responses. 

[0030] Fig. 3C shows the format of the AKE control 
commands. The algorithm field 201 in the AKE control 
commands set informs of an executed information 
exchange procedure when the value of the algorithm ID 
200 is 0. Only one bit in the algorithm field 201 of the 
AKE control command and the response to AKE control 
commands is set at 1 , and the other bits are 0. A bit hav- 
ing the value 1 indicates the information exchange pro- 
cedure being used. A label 202 is used for identifying 
correspondence between AKE control commands. For 
example, let's say a certain information exchange pro- 
cedure specifics that the device receiving an AKE con- 
trol command needs to return a different AKE control 



command corresponding to the AKE control command 
received when the AKE control command is sent from 
one device to another. In this case, the label 202 
inserted in the returned AKE control command will have 

5 the same value as the label 202 inserted in the first AKE 
control command received, in order to clarify the corre- 
lation between both AKE control commands. In step No. 
203, a serial number from 1 is given to each AKE control 
command in the sequence of communication in the 

10 information exchange procedure. 

[0031] A subfunction 299 takes the values shown in 
Table 1. and the meaning of each AKE command is 
determined by these values. 



Table 1 



Subfunction 


Value 


Make-response 


0016 


Verify-me 


0116 


Create-key- 


1016 


Reconstruct-key 


1116 


Exchange 


2016 



[0032] If the subfunction 299 is the make-response, 
this AKE control command challenges the authentica- 
tion of the device receiving this command. Here, the 

30 data 207 contains authentication challenge data 
expressed as random numbers to authenticate the 
receiving device. The device receiving this command 
returns an AKE control command whose subfunction 
299 is set to verify-me. 

35 [0033] When returning the AKE control command, the 
data stored in the data 207 is the authentication 
response data which is a result of a predetermined 
operation with respect to the authentication challenge 
data in the received data 207. The key information used 

40 for this operation is a key given only to an authorized 
device in advance. Whether the device executing the 
operation is an authorized device or not can be deter- 
mined by checking the returned authentication 
response data. 

45 [0034] If the subfunction 299 is the create-key-infor- 
mation, this AKE control command requests the encryp- 
tion key 109 to the device receiving this command. The 
device receiving this AKE control command returns the 
AKE control command whose subfunction 299 is set to 

so reconstruct-key. At this point, the encrypted encryption 
key 1 09 is stored in the data 207 and returned. 
[0035] If the subfunction 299 is the exchange, this 
AKE control command requests the exchange of key 
information between devices sending and receiving the 

55 command. This key information is stored in the data 207 
and transferred for indirect authentication between 
devices or the creation of a common key. 
[0036] Values other than those specified in Table 1 are. 
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reserved for future extension. The channel No. 204 indi- 
cates the channel number for isochronous communica- 
tion between the sending device 110 and receiving 
device 128. This channel No. 204 is valid only when the 
subfunction 299 is set to the create-key-information or 
reconstruct-key. In other cases, this value will be set to 
FF in hexadecimal format Block No. 205 and total block 
No. 206 are used when data which should be handled 
by the AKE control command cannot be sent by one 
AKE command. In this case, applicable data is divided 
into blocks, and transferred in several transmissions. 
The total block No. 206 indicates the number of divided 
blocks in applicable data. The block No. 205 indicates 
the number of each block in the data 207. The data 
length 209 indicates the valid data length, as bytes, in 
the data 207. The data 207 is data exchanged by the 
AKE control command. The device receiving the AKE 
control command returns a response to that specific 
AKE control command. The format and value of the 
response are the same as those of the received AKE 
control command. The only detail which differs is that 
the response does not contain the data 207. 
[0037] Fig. 4 shows a chronological example of AV/C 
commands which are exchanged between the sending 
device 1 10 and receiving device 128 before sending the 
encryption keys 109 and 126 from the sending device 
110 to receiving device 128. First, operations of both 
devices before exchanging AV/C commands shown in 
Fig. 4 are briefly described. 

[0038] An initial condition is that non-encrypted TSP 
is sent from the sending device 110. The TSP output 
from the signal source 1 00 is input to the encrypter 101 . 
Since the output command 105 is set to the normal out- 
put, the encrypter outputs TSP as it is without encryp- 
tion to the source packet generator 102, and registers 
the value 0 as the encrypting information 910. The 
source packet generator 102 adds 4-byte source packet 
header to the TSP received, and outputs it to the CIP 
block generator 103. The CIP block generator 103 adds 
8-byte CIP header 954. and outputs it as isochronous 
payload 952 to the isochronous packet generator 107. 
Here, the encrypting information 910 contained in the 
CIP header 954 is 0 which is input from the encrypter 
101. The isochronous packet generator adds the iso- 
chronous packet header 900, header CRC 901. and 
data CRC 903 to the received isochronous payload 952 
to create the isochronous packet. This isochronous 
packet is output to the 1 394 bus 1 1 1 by the 1 394 packet 
I/O means 108. Since the applicable isochronous 
packet conforms to the AV protocol, the tag 907 in the 
isochronous packet header 900 is set to 1 . 
[0039] When the TSP output from the signal source 
100 is changed, which means that AV information 
changes from that unprotected AV information to copy- 
protected AV information, the key generator 106 detects 
this change, and changes the output command 105 
from the normal output to empty output. At the same 
time, the encryption key 109 tor encrypting TSP is given 



to the encrypter 101. 

[0040] When the output command 105 is for empty 
output, the encrypter 101 outputs an empty signal to the 
source packet generator 102 every time it receives a 
5 TSP from the signal source 1 00, and registers the value 
1 as the encrypting information. At receiving the empty 
signal from the encrypter 101 , the source packet gener- 
ator 102 transmits the received empty signal as it is to 
the CIP block generator 103 without adding the source 
10 packet header. When the CIP block generator 103 
receives the empty signal, it outputs only the CIP 
header 954 to the isochronous packBt generator 107. 
Here, the encrypting information 910 in the CIP header 
954 uses the value 1 output from the encrypter 101. The 
is isochronous packet generator 107 creates an iso- 
chronous packet as the isochronous payload 952 using 
the CIP header 954 received from the CIP block gener- 
ator, and outputs it to the 1394 packet I/O means 108. 
Since this isochronous packet conforms to the AV proto- 
20 col, the value of the tag 907 is set to 1 . The 1 394 packet 
I/O means 108 outputs received isochronous packet to 
the 1394 bus 111. This isochronous packet is continu- 
ously output, and the isochronous packet only contain- 
ing the CIP header 954 in this isochronous payload 952 
25 is continuously output to the 1 394 bus 111. The receiv- 
ing device 1 28 receiving this isochronous packet checks 
its tag 907 by the 1394 packet I/O means 127, detects 
that the isochronous packet conforms to the AV proto- 
col, and then outputs this isochronous packet to the 
30 payload extractor 123. The payload extractor 123 
extracts the isochronous payload 952 from received iso- 
chronous packet, and outputs it to the actual data 
extractor 122. The actual data extractor 122 outputs the 
encrypting information 910 and source ID 906 in the 
35 CIP header 954 to the key generator 1 25. After the key 
generator 125 detects that the value of the encrypting 
information 910 is 1, the receiving device 128 learns 
that device outputting the isochronous packet from the 
source ID 906 is the sending device 1 10. Then, the key 
40 generator 1 25 finally goes onto a process for requesting 
the encryption keys 109 and 126 using the A/C com- 
mands, as shown in Fig. 4. 

[0041 ] In Fig. 4, the AKE status command 300 is first 
sent from the receiving device 128 to sending device 

45 110. This enables the receiving device 128 to query 
information exchange procedure that can be used by 
the sending device 110. Replying to this query, the 
sending device 110 returns the AKE response 301 to 
the receiving device 128. Information exchange proce- 

so dure which the sending device 110 can execute is 
assigned in bits in the algorithm field 201 of the AKE 
response 301. This allows the receiving device 128 to 
learn which information exchange procedures can be 
executed by the sending device. For example, if the 

55 sending device 110 can execute the second and sixth 
information exchange procedures, binary indication in 
the algorithm field 201 of the AKE response 301 will be 
0000000000100010. 
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[0042] The receiving device 128 receiving the AKE 
response 301 selects one optimal procedure from infor- 
mation exchange procedures that both sending device 
110 and receiving device can axecute. Then, AV/C com- 
mands are exchanged according to the selected 
exchange procedure. Let's say the receiving device 128 
can execute the second and eighth information 
exchange procedures. Then, the information exchange 
procedure which can be executed by both sending 
device 110 and receiving device 128 is only the second 
procedure. Accordingly, the rest of authentication and 
information exchange are executed using the second 
procedure. In the AKE control command in this proce- 
dure, the value of algorithm ID will be 0 and the value of 
the algorithm field 201 will be 0000000000000010 in 
hexadecimal indication. The information exchange pro- 
cedure specifies not only the sequence of exchanging a 
range of AKE control commands but also a format and 
processing method of the data 207 sent by each AKE 
control command. 

[0043] In accordance with the second information 
exchange procedure, the key generator 125 sends the 
make response command 302 to the sending device 
110. In the data 207 of this make response command 
302, two random numbers RRa and RRb generated by 
the key generator 125 are encrypted, and the algorithm 
field 201 contains identification information indicating 
the use of the second procedure. The key used for 
encryption is a common secret key given to both author- 
ized sending device and receiving device in advance. 
The key generator 106 receiving the make-response 
command 302 checks the algorithm field 201 of the 
received make-response command 302, and learns to 
use the second procedure for the rest of authentication 
and information exchange. Since the key generator 106 
can execute the second procedure, the key generator 
1 06 knows that the data 207 of the make response com- 
mand 302 sent in accordance with this second proce- 
dure contains two random numbers encrypted by this 
secret key. After taking out two random numbers RRa 
and RRb from the data 207 using this secret key, the key 
generator 106 returns a response 303 to inform that a 
response can be generated. Then, the key generator 
1 06 stores one of the random numbers RRa taken out in 
the data 207, and sends the verify-me command 304 to 
the receiving device 128. This is the response 
requested by the previous make-response command 
302. Hereafter, the algorithm field 201 of each AKE 
command exchanged between the sending device 110 
and receiving device 128 always contain the identifica- 
tion information indicating the second procedure. 
[0044] The key generator 125 receiving the verify-me 
command 304 confirms that RRa in the data 207 con- 
forms to the random number RRa generated by itself, 
and then returns a response 305 to the verify-me com- 
mand 304 to inform that verification has completed suc- 
cessfully. The key generator 125 then finally 
authenticates that the sending device 1 10 is an author- 



ized sending device. 

[0045] The sending device 1 10 then use the make- 
response command 306 and verify-me command 308 in 
accordance with the procedures alter the make- 

5 response command 302 described above to confirm 
that the receiving device 128 is an authorized receiving 
device. However, the random number used here is RTa 
and RTb. and the random number sent back by the ver- 
ify-me command 308 is RTb. 

w [0046] Now that both sending device 1 1 0 and receiv- 
ing device 128 know the random numbers RRb and 
RTb, and have confirmed that both are authorized 
devices, the key generator 106 and key generator 125 
separately generates a temporary key (not illustrated) 

is from RRb and RTb using a common operation method 
specified by the second procedure. These temporary 
keys are a common key only between the sending 
device 110 and receiving device 128. 
[0047] Next, the key generator 1 25 sends the create- 

20 key-information command 310 to the sending device 
110. A channel number of the isochronous packet that 
the receiving device 128 is currently receiving is stored 
in the channel No. 204 of the create-key-information 
command 310. The key generator 106 receiving this 

25 create-key-information command 310 encrypts the 
encryption key 109 to be used for encrypting TSP with 
the aforementioned temporary key. and then returns a 
response 311 to inform that the create-key-information 
command 310 has completed successfully. Then, the 

30 key generator 1 06 sends the reconstruct-key command 
312 which stores the encryption key 109 encrypted by 
the temporary key in its data 207 to the receiving device 
128. The key generator 125 uses the temporary key to 
decrypt the data 207 of the reconstruct-key command 

35 312 received, and obtains the encryption key 126. 
Then, the key generator 125 returns a response 313 to 
inform that the reconstruct-key command 31 2 has com- 
pleted successfully. Since the encryption keys 109 and 
126 are encrypted and decrypted using the same tem- 

40 porary key, they are the same keys. The encryption key 
126 is output from the key generator 125 to the 
decrypter 121. This completes the procedure for grant- 
ing decrypting information. 

[0048] The key generator 106 which has sent the 
as reconstruct key command 312 outputs the output com- 
mand 105 for encrypted output to the encrypter 101. 
The encrypter 101 receiving this command encrypts 
TSP received from the signal source 100 by the encryp- 
tion key 1 09, and starts to output it to the source packet 
so generator 102. This enables the sending device 1 10 to 
send the isochronous packet containing TSP encrypted 
by the encryption key 109 in its isochronous payload 
952 on the 1349 bus 111. This isochronous packet 
received by the receiving device 1 28 is decrypted by the 
55 decrypter using the encryption key 126 as described 
above, and outputs the decrypted packet to the AV gen- 
erator 120. 

[0049] In the above series of AKE control commands. 
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each set of the make response command 302 and ver- 
ify-me command 304; make-response command 306 
and verify-me command 308; and create-key-informa- 
tion command 310 and reconstruct-key command 312, 
respectively has the same label 202. The make- 
response command 302, verify me command 308, cre- 
ate-key-information command 310, and reconstruct key 
command 312 also have values 1,2,3, 4, 5, and 6 in the 
step No. 203 respectively. 

[0050] If the actual data 1 05 in the isochronous packet 
output from the sending device 110 changes from 
encrypted actual data 105 to non-encrypted actual data 
105, the decrypter 121 detects the change in the 
encrypting information 910, stops decryption, and out- 
puts the data received from the actual data extractor 
122 as it is to the AV generator 120. 
[0051 ] If a bus reset occurs in the 1 394 bus 1 1 1 after 
the aforementioned processes shown in Fig. 4 starts, 
the procedures after and make-response command 302 
need to be repeated. 

[0052] As described above, in the preferred embodi- 
ment of the present invention, the sending device sends 
encrypting information which indicates the encryption 
status of the actual data in the isochronous packet 
together with the actual data. This enables the receiving 
device receiving the isochronous packet to make a 
request to the sending device for an encryption key for 
decrypting the actual data if the receiving device 
detects, by checking the encrypting information in the 
isochronous packet, that the data is encrypted. The 
sending device receiving the request then gives the 
encryption key to the receiving device. Accordingly, the 
data transfer method of the present invention offers 
extremely simple procedures for giving the encryption 
key from the sending device to receiving device for 
decryption. 

[0053] Moreover, in the preferred embodiment of the 
present invention, the isochronous packet transferred 
via isochronous communication contains i) encrypting 
information indicating the encryption status of the actual 
data and ii) actual data, but only the actual data is 
encrypted for data transfer. This makes possible a data 
transfer method which has no risk of erroneous opera- 
tion when a conventional receiving device receives 
encrypted actual data while maintaining compatibility 
with the conventional data transfer method. 
[0054] Furthermore, in the preferred embodiment of 
the present invention, the CIP header remains non- 
encrypted for transfer even if encryption of synchronous 
data starts while the receiving device is continuously 
receiving synchronous data sent by the sending device. 
This enables a data transfer method which eliminates 
the possibility of erroneous operation of the receiving 
device receiving the data. 

[0055] In the preferred embodiment once encryption 
by the encryption key starts, actual data in all transfer 
units is encrypted and sent However, it is not necessary 
to encrypt all units of data to be transferred. For exam- 



ple, even if both encrypted transfer units and non- 
encrypted transfer units are sent alternately the receiv- 
ing device can correctly decrypt the data because 
encrypting information is included in the CIP header, 

5 thus achieving the same effect. In addition, it is apparent 
that the same effect is also achievable even if the receiv- 
ing device specifies a percentage of encrypted transfer 
units to the sending device. The size of the MPEG 
source packet is 192 bytes, with more than one source 

10 packet stored in one isochronous payload in the case of 
the high data rate transfer of MPEG (12 Mbps mini- 
mum). Naturally, however, it is not possible to have both 
encrypted source packet and non-encrypted source 
packet in the same isochronous payload. 

is [0056] In the preferred embodiment, all actual data is 
encrypted using the encryption key. However, it is not 
necessary to encrypt all pieces of data. For example, 
the same effect is achievable by encrypting the first half 
of the actual data, or encrypting the first and third quar- 
to ters of the actual data, in this case, the receiving device 
can decrypt appropriately, if. when sending the data, 
information is inserted to indicate encrypted portions 
and their percentage in the CIP header. The same effect 
is also achievable by inserting in the CIP header 

25 encrypting information announcing whether the actual 
data is encrypted or not. The receiving device queries 
the sending device via asynchronous communication 
about which part of the actual data is encrypted and to 
what level, when the receiving device detects encryp- 

30 tion by checking the CIP header. The same effect is also 
achievable in this case even when the receiving device 
specifies the encryption area and percentage to the 
sending device via asynchronous communication. If 
only the confidential portion in the actual data is 

35 encrypted, the burden for encryption and decryption is 
reduced, and at the same time, a sufficient effect of 
encryption may be achieved. 

[0057] In the preferred embodiment, the isochronous 
packet containing only the CIP header without actual 

40 data is transferred until the completion of mutual 
authentication between the sending and receiving 
devices. However, the same effect is achievable even 
when an isochronous packet containing encrypted 
actual data is output from the start, and not the iso- 

45 chronous packet containing only the CIP header. 

[0058] In the preferred embodiment, procedures for 
transferring the AKE control commands between send- 
ing and receiving devices are determined by mutual 
negotiation. However, if the receiving device features 

so only one executable procedure, the same effect is 
achievable by starting to transfer commands immedi- 
ately, without executing this negotiation procedure, 
using only the executable procedure. In this case, it may 
be preferable to specify in advance a basic minimum of 

55 executable procedures for all authorized devices. 

[0059] In this preferred embodiment, direct authenti- 
cation is implemented between the sending and receiv- 
ing devices, following which decrypting information is 



8 



15 



EP0 978 965 A1 



16 



transferred using a secret key. However, the means for 
transferring authentication and decrypting information is 
not limited to this procedure. For example, a public key 
may be used for mutual indirect authentication and the 
creation of a temporary key. Decrypting information may 
then be transmitted using this temporary key. Such pro- 
cedures are briefly described below. 
[0060] The sending and receiving device stores the 
key information necessary for mutual indirect authenti- 
cation in the data 207 of the AKE control commands, 
and send this information to each other in line with a 
procedure determined by mutual negotiation. Here, the 
subfunction 299 is set to the exchange. This enables 
both sending and receiving devices to share the same 
temporary key if they are both authorized devices. 
Decrypting information is then transferred using the cre- 
ate-key-information command and reconstruct-key 
command in accordance with the same procedures as 
those described in the preferred embodiment. 
[0061 ] In the preferred embodiment, the procedure for 
transferring AKE control commands exchanged 
between sending and receiving devices is determined 
by mutual negotiation. If the types of procedures execut- 
able by the sending device are known in advance, the 
same effect is achievable by having the receiving device 
transfer commands using a procedure executable by 
the sending device without first executing this negotia- 
tion procedure. 

[0062] In the preferred embodiment, procedures for 
transferring AKE control commands exchanged 
between sending and receiving devices are determined 
by mutual negotiation. However, the method for deter- 
mining transfer procedures is not limited to this one. 
More specifically, if priority is given in advance to each 
of several transfer procedures, the receiving device may 
start to transfer using the procedure given the highest 
priority which is executable by itself. If the sending 
device cannot execute that procedure, the receiving 
device tries to transfer data by going down the list of 
procedures in order of priority until a procedure that is 
executable by both the sending and receiving device is 
found. The AKE control commands are then transferred 
using this procedure to achieve the same effect. 
[0063] In the preferred embodiment, the sending 
device encrypts decrypting information which is used for 
decrypting actual data before transferring it to the 
receiving device. However, the way the receiving device 
obtains decrypting information is not limited to this pro- 
cedure. In other words, the sending device may provide 
the receiving device sufficient information for obtaining 
decrypting information, without transferring encrypted 
decrypting information, and the receiving device may 
obtain decrypting information indirectly from this infor- 
mation. More specifically, the sending device transfers 
only the type of hash function to the receiving device, 
and the receiving device obtains decrypting information 
using the received type of hash function to achieve the 
same effect. 



[0064] The preferred embodiment described above 
comprises an example of the AKE command format. 
However, the AKE command format is not limited to this 
one. In other words, the AKE command format indicated 
5 in this embodiment is just one example of how the pre- 
ferred embodiment may be realized. The same effect is 
achievable by using commands in a different format. 

Industrial applicability 

10 

[0065] As described above, the present invention has 
the significant effect of realizing a data transfer method 
using extremely simple procedures for passing key 
information from the sending device to the receiving 

is device for decryption. Encryption identification informa- 
tion indicating the encryption status of actual data in 
synchronous data is sent together with actual data. The 
receiving device receiving the synchronous data checks 
the encryption identification information in the synchro- 

20 nous data, and if it detects that the actual data is 
encrypted, the receiving device requests the sending 
device for decrypting information for decrypting the 
encrypted data. The sending device receiving this 
request gives the decrypting information to the receiving 

25 device. 

[0066] The present invention has another significant 
effect of realizing a data transfer method which elimi- 
nates the possibility of erroneous operation of the 
receiving device even if conventional receiving device 

30 receives encrypted synchronous data, while maintain- 
ing compatibility with a conventional data transfer 
method. Synchronous data transferred through syn- 
chronous communication contains i) encryption identifi- 
cation information indicating encryption status of the 

35 actual data and ii) actual data, but only the actual data 
is encrypted for data transfer. 

[0067] The present invention has still another signifi- 
cant effect of realizing a data transfer method which 
eliminates the possibility of erroneous operation of the 

40 receiving device even if encryption of synchronous data 
starts while the receiving device continuously receives 
synchronous data sent from the sending device. Syn- 
chronous data transferred through synchronous com- 
munication contains i) encryption identification 

45 information indicating encryption status of the actual 
data and ii) actual data, but only the actual data is 
encrypted for data transfer. This enables to transfer the 
CIP header as it is without being encrypted. 
[0068] The present invention has still another sign'rfi- 

50 cant effect of realizing a data transfer method which 
always executes the most suitable procedure even 
when new and conventional devices share the same 
network. A procedure for both authentication and 
decrypting information with good future extendibility are 

55 achievable by selecting a procedure for providing 
authentication information and decrypting information 
exchanged between the sending and receiving devices 
by negotiation between the sending and receiving 



9 



17 



EP 0 978 965 A1 



18 



devices. In other words, even if a new authentication 
method or decrypting information become available in 
the future, the most suitable procedure will remain 
selectable by negotiation between devices even if a 
device which can use the new procedure and a device 5 
which can use only conventional procedures share the 
same network, as long as the new device is back-com- 
patible with older procedures. 

[0069] The present invention has still another signifi- 
cant effect of realizing decryption even if software which 10 
has a low encryption/decryption processing rate is 
used. The present invention allows the relative propor- 
tion of encrypted actual data and non-encrypted actual 
data to be varied within a single file. Accordingly, even if 
the receiving device has no exclusive hardware for high- is 
speed data decryption, software can be used instead. 
More specifically, even if the receiving device has no 
hardware for decryption like PC, rapid processing is 
made possible by reducing the proportion of encrypted 
data in the file and thus shortening the time required for 20 
the decryption process. 

[0070] The present invention has still another signifi- 
cant effect of realizing a data transfer method which 
uses the limited bus transfer band efficiently and signifi- 
cantly reduces the risk of unauthorized device receiving 2s 
readable data. Unless the sending and receiving 
devices mutually authenticate that both are authorized 
devices, isochronous packets without actual data are 
output 

30 

Claims 

1. A method for transferring data on a bus system in 
which both isochronous communication and asyn- 
chronous communication are employed; said iso- 3S 
chronous communication is for any device on the 
bus to receive synchronous data; said asynchro- 
nous communication is for a predetermined device 
to receive asynchronous data; said synchronous 
data may contain actual data; said synchronous 40 
data also contains encryption identification informa- 
tion at an area other than said actual data; said 
encryption identification information indicates the 
status of encryption of said actual data; and 
encrypted actual data is decrypted using decrypt- 45 
ing information obtained through the following 
steps: 

a) a receiving device receiving said synchro- 
nous data makes a request for decrypting infor- so 
mation of said actual data to a sending device 
sending said synchronous data via said asyn- 
chronous communication, if said encryption 
identification information indicates that said 
actual data is encrypted; ss 

b) said sending device receiving said request 
sends one of: 



i) encrypted decrypting information of said 
actual data; and 

ii) data required for obtaining said decrypt- 
ing information to said receiving device via 
said asynchronous communication; and 

c) said receiving device executes one of: 

i) taking out said decrypting information 
from said encrypted decrypting information 
when said receiving device receives said 
encrypted decrypting information; and 

ii) obtaining said decrypting information 
using said data for obtaining said decrypt- 
ing information when said receiving device 
receives said data for obtaining decrypting 
information. 

2. The method for transferring data as defined in 
Claim 1 , wherein a plurality of types of procedures 
are available between the steps of detecting 
encryption of said actual data and obtaining said 
decrypting information by said receiving device 
receiving said synchronous data; and said receiv- 
ing device executes the next steps for obtaining 
said decrypting information before requesting said 
decrypting information: 

i) querying said sending device of types of pro- 
cedures executable by said sending device; 

ii) selecting a procedure from those executable 
by both sending device and receiving device; 
and 

iii) obtaining said decrypting information in 
accordance with said selected procedure. 

3. The method for transferring data as defined in 
Claim 2, wherein said procedure is selected in 
accordance with a predetermined priority when 
there are a plurality of procedures executable by 
both of said sending device and said receiving 
device. 

4. The method for transferring data as defined in 
Claim 1 , wherein a plurality of types of procedures 
are available between the steps of detecting 
encryption of said actual data and obtaining of said 
decrypting information by said receiving device 
receiving said synchronous data; and said receiv- 
ing device executes the next steps for obtaining 
said decrypting information: 

i) starting said procedure selected from said 
plurality of types of procedures in accordance 
with a predetermined priority; 

ii) re-selecting one of said procedures until said 
procedure executable by said sending device is 
found when the procedure selected by said 
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receiving device is not executable by said 
sending device; and 

iii) obtaining said decrypting information in 
accordance with the selected procedure when 
a procedure executable by said sending device 
is found. 

5. The method for transferring data as defined in one 
of Claims 2 to 4, wherein said asynchronous data 
transmitted between said sending device and said 
receiving device in accordance with said selected 
procedure contains an identifier for indicating the 
type of said procedure executed. 

6. The method for transferring data as defined in one 
of Claims 1 to 5, wherein said receiving device 
authenticates whether said sending device is an 
authorized sending device before making a request 
for said decrypting information. 

7. The method for transferring data as defined in one 
of Claims 1 to 5, wherein said sending device 
receiving a request for said decrypting information 
authenticates that said receiving device is an 
authorized receiving device before sending 
encrypted decrypting information of said actual 
data after confirming. 

8. The method for transferring data as defined in one 
of Claims 1 to 5, said sending device and said 
receiving device mutually authenticate that both are 
authorized sending device and receiving device 
before said receiving device makes a request for 
said decrypting information. 

9. The method for transferring data as defined in one 
of Claims 1 to 8, wherein the next steps are exe- 
cuted before said receiving device makes a request 
for said decrypting information: 

i) said receiving device sends information 
required by said sending device at least for cre- 
ating a common key to said sending device; 
and 

ii) said sending device sends information 
required by said receiving device at least for 
creating said common key to said receiving 
device; 

and then said sending device encrypts decrypt- 
ing information using said common key and 
sends said encrypted decrypting information; 
and said receiving device takes out said 
decrypting information from said encrypted 
decrypting information received using said 
common key. 

10. The method for transferring data as defined in one 
of Claims 1 to 5, wherein only said actual data is 



encrypted. 

1 1 . "Hie method for transferring data as defined in one 
of Claims 1 to 5, wherein said sending device has a 

5 signal source of said actual data inside and deter- 

mines encryption of each of said actual data in a 
fixed length unit output from said signal source; and 
said sending device places encrypted actual data 
and non-encrypted actual data in different output 

10 units of said synchronous communication, and then 
outputs them to said bus system. 

12. The method for transferring data as defined in 
Claim 1 1 . wherein said receiving device specifies a 

is percentage of said encrypted actual data and said 
non-encrypted actual data to said sending device 
using said asynchronous communication; and said 
sending device changes the percentage of encryp- 
tion in accordance with said specification. 

20 

13. The method for transferring data as defined in one 
of Claims 1 to 5, wherein said sending device has a 
signal source of said actual data inside, and deter- 
mines a percentage of encryption of said actual 

25 data in a fixed length unit output from said signal 
source; and said sending device places said actual 
data in an output unit of said synchronous commu- 
nication, and then outputs it to said bus system. 

30 14. The method for transferring data as defined in 
Claim 1 3, wherein said receiving device specifies a 
percentage of said encryption to said sending 
device using said asynchronous communication, 
and said sending device changes the percentage of 

35 encryption in accordance with said specification. 

15. The method for transferring data as defined in one 
of Claims 1 to 5, wherein said sending device sends 
said synchronous data excluding said actual data 
40 until at least said decrypting information is 
requested; and said sending device starts sending 
synchronous data containing said actual data only 
. after at least receiving said request for said decrypt- 
ing information. > 

45 
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